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I. Executive Summary 



Information Technology as a Foundation for DoD Improvement 

Almost all organizations these days confront increased demands for efficiency and 
responsiveness to the markets they serve. Managers of information technology find 
themselves in the thick of the fray, because most of their organizations are looking to 
information technology as one of the primary means of coping with worldwide 
competition. It is difficult to think of any substantial challenge facing these organizations 
— improved service or product quality, reduced cycle times for all their business 
functions, improved coordination across far-flung activities, more efficient use of 
resources — for which information technology does not contribute something to the 
solution. 

With the largest single pool of information technology in the world, the 
Department of Defense (DoD) is by no means immune from these effects. The dramatic 
political and military changes that have occurred in the world over the past couple of 
years call for corresponding changes in the way DoD does business. Leaders within and 
outside of DoD are challenging each activity to justify its contribution to national defense 
and to reduce its costs as much as possible consistent with its essential missions. Like 
most other large organizations, DoD is looking to information technology as a 
fundamental building block of any long-term improvement program. DoD’s Corporate 
Information Management (CIM) initiative constitutes a critical component of any such 
program. 
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USAGE — A Leader in Applying Information Technology 

An important principle of the CIM initiative is to identify the best practices within 
DoD agencies so that they can be borrowed and emulated throughout the Department. 
The U.S. Army Corps of Engineers (USAGE) provides just such a model- its business 
re-engineering strategy. It has, in fact, been recognized by the Director of Defense 
Information, for a "golden nugget" award that signifies leadership in applying 
information technology. USAGE demonstrates how an agency can effect major changes 
through the intelligent use of information technology. The Corps strategy appears to be 
quite capable of being applied in other organization within DoD, the Federal government, 
and, indeed, the private sector. 

USAGE and Business Re-Engineering 

USAGE is the largest engineering organization in the world, with an annual 
budget of $9 billion. It supports DoD construction activities, handles large civil works 
programs, and contracts with various governmental agencies to perform a wide variety 
of civil engineering works. The largest single source of funding comes from the outside 
contracts, for which it has to compete with private-sector engineering firms. It thus has 
ample incentive to strive for efficiency and effectiveness. 

Through the early 1980’s, USAGE’S experience with computer-based systems was 
much like many large organizations. A large variety of systems were developed by 
subgroups within the Corps. This was done with little or no high-level support or 
direction. The resulting "stovepipe" systems may have met the needs of individual 
functional groups, but there existed almost no integration across functions. As a result, 
USAGE information systems suffered from a great deal of duplication and 
inconsistencies, and failed to meet the overall goals of the organization. 

In 1982, the General Accounting Office issued a critical report on data processing 
practices within USAGE. The report criticized, among other things, the lack of central 
direction for Information Systems (IS) activities, the absence of a coherent IS plan linked 
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to the Corps’ missions, the unnecessary duplication of functions and data, and 
inconsistent acquisition policies for hardware and software. 

The USAGE Action Plan 

The GAO report galvanized USAGE into action. By 1984 an Information 
Systems Plan was issued. It proposed the appointment of the Deputy Commanding 
General — the second in command of the Corps — as the senior IRM official. An 
Information Resource Management Steering Committee was established. Composed of 
12 high-level functional managers, plus non-voting IS managers, the Steering Committee 
oversees USAGE IS policies. A subset of this committee forms an Executive Committee, 
which meets weekly to provide continuous policy direction. Supporting these governance 
bodies are other committees that deal with such matters as defining functional 
requirements and establishing data standards. 

Based on the results of the Information Systems Implementation Plan (ISPI) 
conducted in 1985, a project slate of proposed candidates for re-engineering were 
identified. The business processes were to be modernized and applications developed 
according to an overall plan that set priorities consistent with the most important 
management needs within USAGE. A communications network was proposed to link all 
USAGE locations. Three consolidated regional processing centers were established to 
serve the organization’s centralized computing needs. Data standards were set to 
facilitate data sharing and reduce data redundancies and inconsistencies. 

The Successful Re-Engineering Process 

USAGE has developed a proven methodology for successfully modernizing 
information systems. The success results from the synergy of pertinent use of well 
proven techniques and involvement of all-level personnel in the re-engineering effort. 
Candidate applications for re-engineering are identified through high-level management 
committees. Those slated for development, become the responsibility of a relatively 
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small development team — typically six to eight members — composed of a mixture of 
functional and technical specialists. The team follows a well-defined process: 

• Define the AS-IS existing system to provide a baseline for considering a new 
alternative. 

• Examine each existing activity to determine whether it should be continued, 
eliminated, or revised. 

• Design alternative TO-BE systems. 

• Build a business case — a cost-benefit analysis — for each alternative design and 
select the most cost effective one. 

• Develop a transition plan to implement the chosen design. 

• Develop a detailed functional design for the application. 

• Acquire the application — preferably through a "commercial off the shelf 
(COTS) product that meets USAGE needs. 

• If no COTS is found, install a pilot implementation through an iterative 
prototyping process that involves careful testing and user reviews. 

• Install the application where appropriate, based on a Corps- wide deployment plan. 

Lessons Learned 

USAGE’S experience provides some valuable guidelines for agencies wishing to 
pursue a successful organization-wide process to deploy information systems. Each 
agency has, of course, its own unique set of requirements and culture. Nevertheless, the 
general process used by USAGE should find widespread applicability. The principal 
lessons learned, which provide valuable guidelines for other agencies with aspirations 
similar to USAGE’ s, are as follows: 

• Top- management support, combined with support at all levels of the organization, 
is essential for any far-reaching program of business re-engineering. 

• Business re-engineering should precede any attempt to develop new information 
systems. 
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A Business re-engineering STRAP is needed for modernization of any process. 

Heavy user participation — gained through committee arrangements and other 
mechanisms — is critical at all levels of the development process. 

Top-level functional managers are needed to serve as "executive champions" of 
an application. 

A well-structured methodology is needed to provide the discipline and guidance 
for the re-engineering process. 

A supportive infrastructure — effective communications networks and data 
sharing mechanisms — is an essential ingredient to a successful IS program. 

A strong organizational commitment to sharing the corporate data assets is 
imperative. 
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II. Foundations for Business Re-Engineering in DoD 



This section serves as a brief introduction to the basic concepts and history that 
could be considered as foundations of a sound business re-engineering process. These 
include: Corporate Information Management (CIM), Total Quality Management (TQM), 
Activity-Based Costing (ABC), and Management of Planned Change. The reader who 
is familiar with these concepts may wish to skip this section. 

A. Towards a Cost-Effective DoD Organization 

Facing deep cuts in government defense spending, military leaders in all areas 
will be challenged to accomplish their mission with a severely limited budget. The costs 
of the current military establishment must be reduced and effectiveness increased if the 
scaled-down military of the future is to be fully capable of responding to challenges 
throughout the world. Military leaders will be forced not only to eliminate waste, but 
also to make improvements in quality and efficiency. Such an effort calls for a 
continuously orchestrated improvement process involving all activities of the 
organization. 

Modem management concepts, including CIM, TQM, ABC, and Business Re- 
Engineering, are widely recognized as critical baseline principles for a modernization 
program. It is important that DoD program managers understand the essence of these 
concepts to successfully harness the synergy of management, re-engineering, and 
prototype application for a more cost-effective DoD organization (Figure 1). 

1 . The Corporate Information Management Initiative 

The CIM initiative, introduced within the Department of Defense (DoD) in 
October 1989, has been heralded as an initiative to improve standardization, quality, and 
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Figure 1 - Basic Building Blocks for Business Re-engineering 



consistency of data from DoD’s multiple information systems.* The program is 
designed to eliminate redundant information systems and software from distributed 
administrative areas. Common applications are consolidated into information resource 
centers that operate under standardized data usage. 

Early in the CIM process, DoD formed an Executive Level Group (ELG), 
comprised of information system specialists from the private sector, to formulate a DoD- 
wide strategy for downsizing the information resource management structure in response 
to the shrinking defense budget. The unique aspect of CIM has been its move away from 



‘GAO/IMTEC 91-17BR "Potential Reductions to Defense’s ADP Budget Request" 
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the concept of management of information systems to one of management of information 
as a valuable resource.^ 



Principle 1 : Customer Satisfaction 

• Your Customer — the function with business process 
authority and performance accountability — defines systems 
requirements, manages implementation and measures results. 

• An information resource organization becomes a fee for 
service technology service center. 

Principle 2: Simplification of Processes Before Computerization 

• The business process must be simplified before it is 
computerized. 

• Apply technology only after you are sure the organization can 
manage the proposed change. 

• Increase effectiveness and reduce cost of the process by 
changing how people work. 

Principle 3: Implementation of Systems Through Prototyping 

• The fastest process, at the lowest risk, is through 
evolutionary improvement of the process. 

• The best learning environment is achieved through frequent 
success. 



Table 1 . CIM Principles 



^Logistic Systems Architects (LSA) White Paper on CIM, USAGE. 
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CIM is founded on three basic principles: customer satisfaction, simplification 
of processes before computerization, and implementation of systems through prototyping 
(Table 1). Implementation of these principles should result in achieving the quality 
value-added continuum shown earlier in Figure 1 . 

The ELG strategy for information management emphasizes a centralized program 
for data standards and process modeling. Data standardization facilitates data sharing and 
provides a clearer view of how information is used within a process. Standardizing a 
data element implies that information must be handled efficiently at a low cost in order 
to preserve its added value to the organization. Through its guidelines, the CIM 
initiative insists that information must be used to simplify the way DoD does business. 

The business process must be simplified before it is computerized. According to 
CIM guidelines, an organization should: 

• Seek a non-computer solution through process simplification and elimination of 
non-value added steps 

• Re-engineer existing systems 

• Use proven system applications 

• Use ‘off-the-shelf software and systems 

• Develop systems that have joint-service applicability 

• Use service-unique systems only if the above guidelines will not meet the 
requirements. 

The key objectives are to identify and establish information requirements, data 
definitions, and formats that allow standardization of automated data processing (ADP) 
systems throughout DoD. 

Ideally, once data standardization is achieved, ADP systems that perform similar 
functions can be integrated into systems that share resources. The following eight 
functional areas have been identified as candidates for integrated information management 
and cost savings: 

• Civilian payroll 

• Civilian personnel 
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• Contract payment 

• Financial operation 

• Government furnished material 

• Medical services 

• Warehousing, shipping, and distribution centers. 

Other areas within DoD (e.g.. Command and Control) that might serve as candidates for 
the CIM initiative are being evaluated. 

The Department of Defense has an annual budget of over $9 billion to acquire, 
maintain, and operate general-purpose ADP systems. It is estimated that $4 billion of 
this amount is spent to develop new computer-based applications and upgrade existing 
systems. An effective use of information technology (e.g., business re-engineering, 
structured analysis and design tools, application generators, etc.) is expected to save 
approximately 25 percent of the system development and procurement costs.^ Additional 
savings can be realized in the future through the operation and maintenance of fewer, 
more integrated systems. 

In anticipation of a potential $1 billion savings in information systems 
development and acquisition costs through CIM, the Office of the Secretary of Defense 
(OSD) has begun a five-year phased reduction of ADP budgets for all member services. 
The plan calls for a $100 million reduction in fiscal year 1991, $200 in 1992, and $300 
million in years 1993 through 1995. 



2. Value- Adding Strategies for Information Systems 

The ELG has identified the following value-adding strategies for information 
systems: 

• Use re-engineering methodologies (e.g., process and data models) to determine 
joint use application. 



^GAO/IMTEC 91-17BR 
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• Employ tools to measure effectiveness and efficiency that compare public and 
private sector business processes and determine future direction for information 
systems. 

• Establish a fee for information service as a way of determining system efficiency. 

• Promote the development of information systems with open system architecture 
to free DoD from proprietary constraints on hardware and software. 

• Enforce data standards to achieve full conformity with Federal Information 
Processing Standards and the Commerce Department’s National Institute for 
Standards and Technology (NIST). 

• Manage information resources to allow rapid deployment of new technology. 

• Educate all establishments within DoD on CIM goals and objectives. 



B. A Framework for Business Re-Engineering 

1. Total Quality Management (TQM) in DoD 

Total Quality Management / Leadership (TQM/TQL) rests heavily on the 
teachings of W. Edward Deming. Deming’s approach to quality control is more than a 
scientific method to improve a worker’s speed of productivity In recognition that 
quality has become a key competitive factor, organizations must be responsive to 
customer needs, concentrate on improvement of process as the never-ending business of 
the enterprise, and promote teamwork among those who carry out the business 
operations. The relationship between improved quality and overall business-success in 
an organization is shown in Figure 2. 

As tangible ways to improve and measure qujility, statistical indicators (e.g., 
trend and variance analysis) provide feedback that show the effects of change. TQM 
utilizes seven graphic tools for measuring and explaining process quality improvement 
(Table 2). The benefits derived from these graphics tools fit well with the four phases 



"Deming defines quality management as "...understanding the customer’s needs and providing 
a product that meets his satisfaction." The "best return" on each dollar spent is the goal. 



12 




(Add -Plan -Do-Check) of the Deming quality improvement cycle (Figure 3). The cycle 
ideally should remain in an endless loop, ever monitoring and improving the quality of 
the process. 

It is important to note that quality control measurements are meant to be a tool 
for change. Unexpected problems could arise if management by numbers became the 
only motivation for applying statistical quality control. 

DoD seeks to spread TQM concepts to the field with leadership geared to change 
(TQL). Management leadership is critical to bringing about necessary cultural changes 
and improve quality within DoD organizations. To achieve this goal, upper DoD 
management has formed an Executive Steering Group (ESG) whose mission is to develop 
the strategic goals of TQM for the organization. 
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FLOW CHART 


Promotes understanding between value 
and cost added steps. 


CAUSE & EFFECT 
DIAGRAM 


Relates positive and negative effects that 
cause variance in quality. 


PARETO CHART 


Bar graph to simplify large data tables 
providing basis for identifying problem 
areas. 


HISTOGRAM 


Bar graph represents the amount of 
variance between results and 
specifications. 


SCATTER DIAGRAM 


Indicates how changes in one variable are 
related to changes in another variable. 


RUN CHART 


Identifies patterns of performance for 
changes in progress. 


CONTROL CHART 


Reveals cause and statistical control of 
variations from standards, along with 
process capability. 



Table 2. Graphic Tools for Measuring Quality Process Improvement 



2. Activity Based Costing 

The CIM initiative stresses cost containment and the elimination of activities that 
do not add value to the business process. Activity Based Costing (ABC) holds promise 
as being an invaluable tool in evaluating and containing costs. 
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Figure 3. Graphic Tools Associated with the Quality Improvement Cycle 



a. The Illusion of Cost Savings 

Supporters of ABC management aggressively argue that traditional methods of 
cost accounting dwell too much on past accounting data in trying to make future 
improvements. ABC as a managerial approach is in stark contrast to traditional cost 
accounting methods that see cost only as a function of output volume. Traditional cost 
accounting techniques examine where monetary resources are expended. Management 
may use such information to determine where budgets can be trimmed to reduce overall 
expenditures within the company. Budgetary reductions often focus on downsizing the 
work force, pay cuts, forced early-retirement, or elimination of research and development 
efforts. The loss of a skilled work force, combined with reduced product research and 
development effort, invariably leads to a reduction in product quality. Cost cutting 
measures, in reality, often present only a "surface patch" to a deeper budgetary problem. 
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The illusion of reduction in operating expense exists, but organizational 
performance decreases due to inferior quality standards. There is only further temptation 
to increase the cost cutting measures to give the Profit & Loss statement another short- 
term gain. Meanwhile, quality issues remain unaddressed. Improving the appearance 
of the income statement often does nothing for an organization’s attempts at maintaining 
its objectives. What is needed is a cost management methodology that examines not only 
where cost are incurred, but also how they are incurred. 

b. Value-Added Awareness 

Consistent use of ABC management provides a measured approach to cost 
reduction. The overall cost often depends on decisions made across department 
boundaries. Across-the-board cost cuts do not adequately address the interrelation of the 
costing decisions. The focus should be on the elimination of those costly activities that 
do not add value, rather than making indiscriminate cuts.* 



*An example of the value-added awareness in the production process using activity based 
costing is provided by the Tektronix Company’s Portable Division, a manufacturer of portable 
electric measuring devices (Shank, p.47). In the face of increased competition for market-share, 
the organization formulated plans to change the way it made its products. Tektronix found that 
traditional cost accounting techniques were "obsolete and restrictive." They were scrapped in 
favor of a cost management system that Tektronix called "accounting for continuous 
improvement." 

The result was an evolutionary overhaul of the previous cost accounting system that led 
to the elimination of the following activities: 

The production work order system 

Standard product cost calculations 

Cost variance reporting 

Flexible budgets procedures for cost control 

The scrap and rework reporting system 

Monthly inventory tracking & reporting 

Accumulation of work in process (WIP) inventory cost 

Monthly summaries reports of financial performance. 

These activities added no increased value to the finished product. They involved 
redundancies in accounting for materials used, logging waste that should not occur in the first 
place, inspecting inefficient procedures instead of correcting them, and producing intermediate 
status reports. Many of these activities were replaced with more modern reporting procedures 
that provide management real time cost analysis information that allows an organization to make 
realistic decisions on production cost. 
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Figure 4. Analysis of Business Activities Based on ABC 



Effective cost management needs to look not only at the cumulative monetary 
amount spent on the product manufactured, but also at the cost of the individual 
processes, or activities, in the production operation (Figure 4), This allows management 
to isolate activities within the production process and evaluate whether certain activities 
are cost-efficient and add sufficient value to the product. 

Activity-Based Cost Management fosters evolutionary change to occur in the 
production process. As cost drivers, activities that are obsolete must be eliminated from 
the process and, if necessary, replaced by alternative procedures. The organization can 
continuously modify activities as part of its cost driver monitoring effort. 
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3 . Management of Planned Change 

Affecting change within a large-scale corporate structure is a complex and 
traumatic process that involves risk, uncertainty, and resistance. However, change is 
necessary if an organization wishes to remain competitive. For a planned change to be 
effective, a large-scale organization such as DoD must take into consideration its size and 
cultural history, depth of change in the organizational hierarchy, and whether the change 
crosses functional areas. 

Areas where change offers substantial opportunities for improvement include: 

• Better relationship between the organizational culture and the competitive 
environment 

• Refinement of the input-output transformation process 

• Improvement of product quality 

• Differentiation, coordination, and integration of effort across functions 

• Human resource management 

With the key areas of change identified, management must realize that designing 
and implementing a planned change involve re-formulating corporate strategies and 
structures, incorporating new technology (including the use of information technology), 
and re-evaluating employee development programs. Procedures to promote information 
exchange, enhance decision making and conflict resolution, and encourage participation 
and cooperation between functional areas should be carefully designed and implemented 
during the change process. 

4. Business Re-Engineering 

The history of business re-engineering began in the early 1980’ s in the 
manufacturing sector. Concepts such as Just-in-Time (JIT) inventory and concurrent 
engineering were developed and often supported by sophisticated computer systems. 
Organizations were forced to carry out new business methods, rethinking the way they 
operated. 
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Business re-engineering is based on the concept that organizations must change 
the way they work in order to effect a major improvement. By breaking down operations 
into manageable and discrete processes, the organization can identify activity areas for 
elimination or improvement. From this point of view, re-engineering is a logical 
outcome of ABC, TQM, and management of planned change. 

Re-engineering involves three steps: 

• Examination of the business process 

• Optimizing the process for efficiency 

• Implementing a new business system (applying information technology when 
appropriate to the new process). 

An effective way to carry out a program of re-engineering is to assemble a team 
that is composed of members representing a broad range of functional areas within an 
organization. The team should analyze existing business processes and activities in an 
attempt to fully understand the current operations. 

Once the current business activities are fully understood, the re-engineering team 
begins to optimize them for efficiency and effectiveness. Graphical and statistical tools 
(such as those used in TQM), ABC , and common sense are applied to assess whether 
an activity adds sufficient value to justify its continuation. The basis for establishing a 
new business process is to enhance the value-added activities and eliminate the remaining 
ones. This approach systematically creates new rules, and a need for modernization. 
Table 3 lists a set of guiding principles for re-engineering. 



5. Re-engineering — Go Versus No-Go 

The decision whether to revamp a business process or to "leave it as is" can be 
very traumatic for most organizations. Talk of any change is often a source of 
contention as to the best path for process improvement. Knowing when to re-engineer 
a business process is perhaps more crucial than the mechanics of knowing how to do it. 



^ Hammer, pp 108-110. 
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Thinking that re-engineering is a panacea for any business process is a trap that must be 
avoided. For this reason, the decision to re-engineer an existing process must not be 
made lightly. 

The following provides some guidance as to whether or not an organization should 
re-engineer:’ 

• The support of top management must be the first factor affecting whether or not 
an organization should engage in a re-engineering program; without such support, 
any fundamental change is almost impossible. 

• Processes that are critical, or of the greatest value, to the organization’s mission 
should take precedence over the ones that are perceived as having less strategic 
impact. 

• It is usually not cost effective to re-engineer a process that will soon be phased 
out. Expected benefits of a re-engineered process may not be able to offset the 
conversion costs. 

• The greater the complexity of a process, the more attractive it becomes as a 
candidate for re-engineering. The complexity of a process may stem from its 
intrinsic nature — e.g., the process may involve a large number of variables and 
complicated or probabilistic relationships among the variables. Re-engineering 
may often exploit information technology to deal internally with the complexity, 
thereby reducing the apparent complexity as seen by the user — "so complex, it’s 
easy," as proclaimed by the ad for the automated camera. 

• An old process that has undergone continual changes and accretions often presents 
an excellent opportunity for re-engineering. An activity that may have started out 
as a clean and simple process gradually becomes more and more convoluted with 
appendages to handle "special cases" and "extensions." Re-engineering can often 
sweep away this accumulated complexity by simplifying the process and 
eliminating unnecessary functions. 

• Although complexity is a difficult phenomenon to measure, experience has shown 
that the more individuals involved in a process the more complex that process is; 
therefore, there is a greater possibility that this process contains non-value adding 
steps. 



’Sittenauer and Olsem of the USAF Software Technology Support Center have constructed 
a self-assessment survey to aid in the decision when to conduct a software re-engineering effort 
("Time to Re-engineer? ". Cross Talk . March 1992, p.21). 
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• Re-engineering is most successful when applied to one process at a time. 
Attempts to change all facets of the business process at once must be avoided, 

• The selected candidate process for improvement will be most successful if the 
organization can nurture a consensual decision-making environment. This allows 
shareholder commitment to the re-engineering effort. 



WHO SHOULD RE-ENGINEER? 

• Non manufacturing firms and high technology firms facing tough 
competition 

• Companies in need of a radical product breakthrough 

• Companies under fire from heavy end-user demands 

• Companies facing financial crisis 

PRINCIPLES OF RE-ENGINEERING 

• Organize around outcomes, not tasks 

• Have those who use the output of the process perform the process 

• Subsume information processing work into the real work that 
produces the information 

• Treat geographically dispersed resources as if the were centralized 

• Link parallel activities instead of integrating their results 

• Put the decision point where the work is performed, and build 
control into the process 

• Capture information once and at the source 



Table 3. Guiding Principles for Re-Engineering 
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In summary, DoD has recognized business re-engineering as a means for 
streamlining business operations. DoD agencies must not simply automate existing 
inefficient business processes; they must completely change the way they operate. 
Information technology is generally an important vehicle to implement change. The 
Corporate Information Management Program reflects this approach.* 



*"The focus of CIM is on management methods and its primary objective is business process 
improvement." - White Paper on CIM, Federal Computer Week, September, 1991. 
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III. USAGE: Re-Engineer or Perish 



A. USAGE and DoD Business Re-Engineering 

The Army Corps of Engineers is the largest engineering organization in the 
world, employing approximately 43,000 civilians and 900 military personnel worldwide. 
It has a history that spans over two hundred years. Its military districts are depicted in 
Figure 5. 

The USAGE mission embraces three major arenas: military construction, civil 
works, and engineering and project management support to agencies within the federal 
government and governments of other nations.’ 

Among other things, USAGE is responsible for construction on both Army and 
Air Force bases. It is currently undertaking projects that coincide with the 
implementation of the Base Realignment and Closure Act of 1988. In 1990, USAGE 
spent $50 million on these activities and estimates that it spent the same in 1991. 
USAGE is also responsible for providing new facilities at the installations that will be 
gaining forces as a result of this Act. 

USAGE also participates in a large civil works program. This includes water 
resource management and emergency response. As part of water resource management, 
USAGE maintains 25,000 miles of inland waterways and approximately 100 major 
seaports, as well as smaller harbors. These waterways are critical to the movement of 



’The general mission of the Corps is "To manage and execute engineering, environmental, 
real estate, research and development, and readiness programs to support the Army, Department 
of Defense, and the Nation during peace and war. Inherent in this mission is providing caring 
leadership and quality products and services consistent with environmental values and the highest 
standards of professional integrity and excellence." 
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Figure 5. USAGE Military Districts and Regional Processing Centers (Note - Civil 
Works Boundaries are not Depicted) 



commercial and military traffic. USAGE constructs and maintains locks and dams, as 
well as dredges navigable waterways. Its Emergency Response Teams assist in areas 
stricken by flood, drought, tornadoes, volcanic eruptions, or similar natural disasters. 
They conduct rescue operations, restore vital transportation links, and restore essential 
resources (such as drinking water) to areas suffering such disasters. 

Projects for federal agencies include construction of space shuttle launch and 
landing facilities for NASA, bulk mail facilities for the U.S. Postal Service, transmitters 
for Voice of America, and facilities for the Department of Energy. Projects for 
governments of other nations vary. Most recently, USAGE was involved in the Kuwait 
recovery program following Operation Desert Storm. 
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The current USAGE total annual budget is $9 billion. In 1990, $354 million was 
spent on information technology, and $7 million was spent on the Information Systems 
Modernization Program.'® Budgetary support for USAGE missions comes from three 
distinct sources. Operations and Maintenance (O&M) funding provides direct 
appropriations for military operations. Givil funds finance the civil works mission of 
USAGE. The third and most significant source of funding is the money received through 
reimbursable programs. These funds are received through the awarding of contracts to 
USAGE by agencies within the federal government and the governments of other nations. 
To win reimbursable projects, USAGE competes with private sector construction firms 
and must sell its services to federal agencies. 

An adverse GAO audit in 1982 forced USAGE to change the way it managed 
information systems. USAGE commenced a massive information systems improvement 
plan encompassing all areas of information management. Beginning in 1983, a 
comprehensive program was devised for modernizing hardware, software, and the 
acquisition and management of information systems. 

With business re-engineering as an essential facet of this modernization effort, 
USAGE wants to be a pioneer that serves as an excellent model for GIM." In April 
1991, USAGE proposed the following nine information systems as interim candidates for 
potential DoD-wide application: 

• Gomputer Aided Gost Estimating System 



'“Interview with Mr. Dave Spivey, Information Modernization Program Manager, Dec 18, 
1991. 



'"'As the CIM model agency. The Corps would establish a program to assist DoD 
organizations and agencies in transitioning to CIM from a functional point of view. Our 
experiences and lessons learned in executing a CIM like philosophy over the years places us in 
a unique position to assist other organizations with their modernization efforts. We already have 
in place many of the supporting mechanisms needed to support others, and we have often been 
called upon to assist Army, DoD, and other government organizations with technical support and 
advice concerning their information programs. To our knowledge, we are the only organization 
in DoD to have undertaken this type of program on an agency-wide basis." Memorandum from 
USACE to Director of Information Systems for Command Control and Computers dated 15 April 
1991, proposing USACE as CIM model agency. 
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• Automated Review Management Systems (ARMS) 

• Computer Aided Design and Drafting (CADD) 

• Architect Engineering Contract Administration Support System (ACASS) 

• PC Economics Package (ECONPAC) 

• Real Estate Management Information System (REMIS) 

• Integrated Facilities System - Micro (IFS-M) 

• Construction Contractor Appraisal System Support (CASS) 

• Corps of Engineers Automated Legal System (CEALS) 

These candidates meet CIM system principles and have been approved for use throughout 
USACE.‘2 

Based on proven systems development techniques, USACE has developed a 
structured approach to business re-engineering. The business re-engineering methodology 
is a generalized and repeatable process that can be taught and implemented effectively.* *^ 

By adopting an adaptive and participatory approach to implementation, USACE 
has enjoyed some early success in dealing with the issue of training, corporate change, 
and all of the challenges associated with the introduction of new business practices in the 
work place. The lessons learned will benefit all organizations desiring to utilize the 
USACE business re-engineering methodology. 



‘^All systems developed under CIM are characterized by the following principles: 

Vendor independent 

Assembled from standard components 

Interoperable 

Single point data entry 

Non-redundant databases* 

Developed using a Life Cycle Management Philosophy 

* In some instances the USACE modernization program incorporates planned redundancy. 

*^is methodology has been described as a "gold nugget” by Paul Strassmann, Director of 
Defense Information, who stated, "We will export the Corps of Engineers Methodology 
throughout the Defense Department." - White Paper on CIM, Federal Computer Week 
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B. Organizational Culture and Management Philosophy 

The Army Corps of Engineers organizational culture is comparable to that of a 
large and successful private sector corporation. USAGE has evolved over its long 
history into an elite organization with a "can-do" attitude towards any and all missions 
assigned, striving to be the best and a leader within DoD. 

Top management philosophy within USAGE is strategic and visionary in nature. 
Senior USAGE officials have identified "corporate effectiveness" as the most strategic 
issue effecting USAGE today.''* The increased effectiveness of operations is essential 
in an era of decreased government spending. The major elements of corporate 
effectiveness for USAGE are: 

• Human Resources 

• Leadership 

• Performance Accountability 

• Corporate Reorganization and Project Management 

• Innovation 

• Management of Information. 

In order to exploit fully the power of available technology, USAGE recognizes 
that it must continue to make fundamental changes in the way USAGE and DoD 
approach work. In the past, information systems were developed to serve separate 
functional areas, with each area building its own vertical ("stovepipe") systems that use 
their own data and imposed almost impenetrable barriers to sharing across systems. 
Information is now recognized as a common resource that must be used to streamline 
operations and change the way business is conducted. Although information technology 
does not drive change, it enables USAGE management to communicate knowledge and 
integration of data in new ways. The ability to access correct information at the right 
time is crucial as both USAGE and DoD become more cost sensitive. Its new 



‘^Modernization Plan 
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technology and development methodology enables USAGE to move toward 
comprehensive systems that allow information sharing throughout the entire organization. 



C. Historical Overview of Information Systems prior to 
Modernization Efforts 

Prior to the modernization effort, USAGE information systems consisted of 
approximately 300 computer-based systems to support administrative functions and over 
10,000 applications to aid scientists and engineers in structural and architectural design, 
research projects, and problem solving. While the scientific and engineering applications 
were up to standards and followed sound professional practices, USAGE realized that 
improvement was necessary in the business practices underlying management information 
systems. 

1. Philosophy towards Management Information Systems prior to 1982 
The standard Gorps of Engineers Management Information System (GOEMIS) was 
developed in 1968. Table 4 provides a list of information systems included in GOEMIS. 
These information system applications were used by USAGE personnel worldwide, and 
had become increasingly important to the effectiveness of the USAGE mission. 

USAGE did not always view information as a valuable resource that can be 
harnessed to increase the effectiveness of an organization. Preoccupied with growth 
issues, top management within USAGE did not provide necessary mechanisms — 
planning, control, direction, and funding — to ensure that information resources were 
effectively utilized. 

In 1982, the management of information systems within USAGE was disparate 
and inconsistent. Dispersed organizations within USAGE were permitted to manage, 
acquire, and use computers in the way they saw fit. ADP management responsibilities 
were widely dispersed among the central office, various program offices, and field 
offices in divisions, districts, research centers, and laboratories. There was no real 
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SYSTEM 


FUNGTION 


FINANGE AND 
AGGOUNTING 


Govering all district level accounting records for 
civil, military, and revolving fund accounts. 


PERSONNEL 

ADMINISTRATION 


Database for staff management requirements and 
authorizations. 


RESOURGE 

ALLOGATION/ 

PROJEGT 

MANAGEMENT 


Reports project management information available in 
the personnel and finance and accounting data files. 


OTHER SYSTEMS 


Transportation Information System, Gomputer Aided 
Engineering and Design, Progress and Divisions 
reporting system. 



Table 4. USAGE Information Systems Prior to 1982 



central authority for managing resources. The Engineering Automation Office was 
established as a central point of management for ADP, but it was given no clear authority 
over the smaller district offices. As a result, any attempt to enforce a centralized policy 
was frustrated by the decentralized management structure. 

2. Effects of Disparate Management Philosophy 

USAGE had numerous ADP activities dispersed worldwide, accompanied by 
inconsistent, incomplete, and ineffective planning. According to GAO, the systems that 
did exist appeared to be fragmented and ineffective, the use of computer equipment 
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throughout USAGE was inconsistent, and attempts at acquisition of modernized 
equipment were futile. Table 5 summarizes the findings of a GAO report in 1982.** 



GAO FINDINGS 

No single focus of responsibility or coherent system for managing 
information resources 

Lack of a formal oversight mechanism to ensure effective and 
efficient management and use of information systems and computer 
software 

No policy for enforcing control of the development of software 
applications 

No comprehensive plan to help manage, acquire, and use 
information resources 

No uniform method for evaluating the use and performance of 
computers and related information resources. 



Table 5. Shortcomings Identified in GAO Audit 



'^Because of continual requests for increased funding for information systems by USAGE, 
the House Appropriations Committee requested that GAO conduct a detailed investigation of 
USAGE information systems management (GAO/CED-82-83). The audit was intended to answer 
the following questions: 

• What was the current status and cost of resources in USAGE? 

• Did the USAGE have an effective management control system for its ADP resources? 

• Was there adequate management control and conversion plaiming for computer software? 

This audit highlighted several shortcomings in USAGE management of information 
resources as depicted in Table 5. These were a direct result of the inconsistent management 
philosophy practiced by USAGE. 
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Most notable was the observation that there were no uniform or standardized 
procedures for systems development. Although USAGE had attempted to standardize and 
monitor systems development by requiring that any development expense in excess of 
$10,000 be approved by the Engineering Automation Office, there were no mechanisms 
in place to enforce the policy. For the most part, systems planning took place within 
separate directorates, with no structured methodology in place to integrate system 
development. 

This fragmented approach led to the creation of vertical un-integrated "stovepipe" 
systems designed to meet the specific needs of departmentalized functional areas. Some 
critical data were unavailable at the corporate level; when available, they were either 
redundant, inconsistent, or inaccessible. Programs were cumbersome to run, with 
overlapping modules. 

The findings of the audit led to a compilation of a list of comprehensive 
recommendations for improvement (Table 6). 



D. Transition to CIM 

The basic philosophy and fundamental principles of the USAGE program for 
Information Resource Management were outlined in March of 1983. The objective of 
the IRM program was to improve the accuracy, completeness, availability, timeliness, 
and usefulness of information for decision makers at all levels. The time line of this 
program is depicted in Table 7. 

In June of 1984, USAGE completed an Information Systems Plan (ISP) for the 
Office of the Ghief of Engineers, presenting the results of a pragmatic, step-by-step 
review of USAGE information systems.** Three objectives were identified: relate 
information requirements to mission, goals, and information systems; recommend 
strategies to improve IRM; and develop an action plan for improvement. Through a 



**" Information Systems Plan for the Office of the Chief of Engineers", June 1984 . 
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GAO RECOMMENDATIONS 



Establish a separate Information Resource Management Office at the 
Headquarters level with clearly defined authority over information 
resource activity. The head of this office should be designated by 
the Chief of Engineers. 

Direct the senior IRM official to develop and implement a 
comprehensive program for managing USAGE information 
resources. 

Establish a comprehensive planning process for information 
resources. 

Systematically update and define functional user requirements to 
better justify the acquisition of additional computer resources, and 
determine requirements of communication. 

Perform a detailed review and analysis of major software systems 
to determine whether they should be continued, redesigned, or 
eliminated. 

Conduct a thorough cost/benefit analysis of alternative redesign 
stratagem for USAGE Management Information Systems to assure 
that the Government incurs the lowest total life cycle cost. 



Table 6. GAO Recommendations 



series of interviews with 55 functional managers, a consensus was reached on key IRM 
issues that must be addressed in the modernization program. Table 8 lists these issues 
in order of priority. The team realized that these issues must be effectively addresses in 
the modernization program (Table 9). 

Following completion of the ISP, the Chief of Engineers directed that an 
Information Systems Planning Implementation (ISPI) report be written dealing with the 
integration of information systems within the Office of the Chief of Engineers.*’ 
Completed in May of 1985, the report developed application, data, and geographic 



‘’"Information Systems Planning Report: A Prescription for Change", May 1985. 
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TRANSITION TO CIM 




1982 


GAO Audit 




JAN 1983 


Modernization Goals and Objectives Outlined 




JUN 1984 


USAGE Information System Planning Report 
Published 




AUG 1984 


Information Resource Management Steering 
Committee Established 




SEPT 1984 


Director of Information Management Established 




MAY 1985 


USAGE Information Systems Planning 
Implementation Report Published 




MAY 1986 


Comprehensive Business Re-Engineering Program 
Commences 




DEC 1989 


12 Requirement Statements Completed 




1990 


26 Prototype Modules Completed 




AUG 1990 


USAGE 1995 Architecture Developed 




PRESENT 


10 Modules Deployed 





Table 7. CIM Transition Timeline: Some Notable Actions 



architectures for USACE-wide information systems. 

The report contained three major sections. The first was a tactical plan that 
contained recommendations as to how USAGE could adjust its current systems planning 
methods to provide for greater integration within the framework of the recommended 
architecture. The plan recommended a reorientation of existing resources to provide for 
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Problem Category 


Manifestations 


Lack of/or incomplete automated 
system 


No automated information system available to satisfy a 
perceived need or a system substantially inadequate. 


Lack of usefulness 


Provides information in quantity or format that is either 
not desired or not needed. 


Inadequate ADP assistance 


A lack of command direction, central database 
administration, or programming capability prevents 
effective automation. 


Unreliable area 


Data are not accurate or consistent. 


Redundancy of data and systems 


Same data are maintained in more than one system, and 
several systems are designed to provide the same 
information. 


Untimeliness of output 


Data are received too late to be useful in understanding 
program status or effecting changes. 


Incompatibility of automated system 


Communications among information systems are 
restricted by hardware, software, or data design 
differences. 


Lack of interactivity 


Users are not able to manipulate or select data from 
USACE standard information systems. 


Inadequate ADP system awareness 


Insufficient training for users of automated systems and a 
lack of aggressive orientation into existing systems, 
which restrict the widest use of automated data. 


Lack of information 


No system exists — automated or non-automated — to 
provide the required information. 


Inadequate non-automated systems 


Non-automated systems exist, but are inadequate 


Technically inadequate ADP systems 


A lack of ADP hardware, software, and/or 
communications capability prevents effective automation. 


Proprietary systems 


"Owners" of automated systems resist the sharing of 
"their" data with others. 


Resource Costs 


Costs verses benefits are difficult or impossible to 
identify. 



Table 8. Key IRM Issues Identified in ISP 
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AREA 


RECOMMENDATION 


Education of Executives 


Implement an intensive program of education 
concerning automation, software, interactive 
capabilities, ADP cost effectiveness, and 
information management. 


Management of Information/ 
Automation 


Establish a strong support organization for 
information resource management. 
Implement an Information Resource 
Management Directorate headed by a 
General Officer or Senior Executive Service 
Civilian. 


Existing System Deficiencies 


Integrate existing systems across functional 
organizations. 


Lack of Automation 


Automation should be developed where 
needed. Personnel and manpower databases 
and office automation support should be 
improved. 


ADP Assistance 


Improve coordination and teamwork between 
ADP community and USACE managers. 



Table 9. Recommendations by ISP Team 



coordinated information and system planning of major systems under the direction of the 
Information Resource Management Steering Committee created in August 1984. 

The second major subsection of the ISPI report was the project slate. The report 
identified applications that should be redesigned to make them more consistent with the 
proposed architecture and more useful to management. Seventeen system design projects 
were identified and ranked in order of importance based upon potential benefits, impact 
on the organization, probability of success, and demand for use (Table 10). 
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PROJECT SLATE 
(Ranked by Priority) 



1) Finance and Accounting 

2) Manpower 

3) Design Tracking 

4) Construction Tracking 

5) Civil Works Program Development 

6) Data Dictionary 

7) Command Operating Budget 

8) Civilian Personnel 

9) Plant Replacement and 
Improvement Program (PRIP) 



10) Real Estate 

1 1) Procurement & Supply 

12) Civil Works Operations 

13) Administrative Support 

14) Strategy, Goals & Objectives 

15) Army Facility Program & 
Budget 

16) Performance Measurement 

17) Safety 



Table 10. Project Slate 



The third area of the ISPI report was the information architecture review. 
Detailed architectures designed to serve as a framework for future systems development 
were defined. They were intended to be used as a tool for planning and coordinating 
information needs over the life of the Information Systems Modernization Plan. 

In May of 1986, USACE began a comprehensive business re-engineering program 
adopting the Structured Requirements Analysis Planning (STRAP) Methodology that was 
aimed at building shared data systems. From the ISP project slate (Table 10), eight 
business processes were identified as a priority for systems re-engineering (Table 11). 
These business processes were systematically reviewed and restructured utilizing the 
USACE methodology for business re-engineering. This methodology has proved itself 
to be very successful, and is the primary focus of this report. The process of re- 
engineering continues today throughout USACE. 
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GRITIGAL BUSINESS PROGESSES 


• 


Project Management 


• 


E-MAIL and Encyclopedia 


• 


Financial Management 


• 


Contracts and Databases 


• 


Real Estate 


• 


Employee Data Extract 


• 


Programs Management 


• 


PAX Data Extract 



Table 1 1 . Critical Business Processes 



1. USAGE Corporate Architecture Strategies 

USAGE formally adopted a new information architecture with the target goal of 
complete implementation by 1995.'* The primary emphasis of the new architecture is 
on a communication network with increased information access, interconnectivity, and 
consolidation of data centers. USAGE organizations and field offices will be able to 
access the network from remote sites through a device interface (DI), a remote job entry 
device, or gateways. The data centers located in Vicksburg, Mississippi, Rockville, 
Maryland”, and Portland, Oregon will form the crux of the network and will be linked 
by a common telecommunications backbone. Application programs will be shared among 
USAGE agencies, and will be accessible by several functional users simultaneously. 
There will no longer be overlapping development of separate systems by functional 
elements within USAGE. 

As a result of the interconnectivity discussed above, databases and applications 
will be shared and centralized. USAGE databases will be dynamic and contain standard 
data elements that will be used by all functional elements within the organization. In the 
new architecture, data are viewed as a resource separate from applications. These data 



'* "Information Planning Guidance: Towards building the 1995 Corporate Architecture", 
May 1991. 



'^Rockville, Maryland site is contractor owned and will not be used for processing. 
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should be captured once at the source and then shared by all users. USAGE will rely 
on the minimal essential data to get the job done. Data will no longer be redundant and 
unstandardized. The overall goal is to improve the accuracy, consistency, and timeliness 
of data, and to facilitate access to information. 

2. Leadership Support and Executive Champions for Change 

Leaders within USAGE are actively involved in the modernization program, 
supervised by the Deputy Gommanding General of the Army Gorps of Engineers, the 
second highest ranking officer within USAGE. As the senior IRM official, he has 
overall responsibility for information resource management. 

Gommittees are an essential facet of the modernization program. The role of 
these committees is to drive USAGE through its modernization effort. Gritical to the 
success of the program is the participation by "executive champions" who are willing to 
take risks and make changes in the way USAGE manages its information resources. 
USAGE seeks out these committee members who are functional managers willing to try 
new methods and re-engineer business practices. 

Figure 6 shows the committees and their functions. The senior governance board 
is the Information Resource Management Steering Gommittee (IRMSG). It is comprised 
of twelve voting members at the General Officer or Senior Executive Service level who 
are appointed by the Deputy Gommanding General. Also included as non-voting 
members are the Program Managers for the Information Systems Modernization 
Program, the Hardware Acquisition Program, and the Director Of Information 
Management. The members of the committee are all top-level functional managers who 
make decisions for USAGE. The Gommittee meets as required, but no less than 
quarterly. 

The Executive Gommittee is a seven-member subset of IRMSG that meets weekly 
and is designed to "keep the pressure on" the program managers and the players in the 
modernization program. 
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Figure 6. Information Resource Management Committees 



There are three subcommittees operating under IRMSC. The Automation 
Configuration Management Board is chaired by the Director of Information Management 
and involves top management in the acquisition and utilization of automation and 
communications. The Data Scrub Review Committee consists of functional managers 
formed on an ad hoc basis to addresses data-specific issues within a given business 
process area. The final subcommittee, the Information Systems Modernization Program 
(ISMP) Proponents Group, advises the Modernization Program Manager on 
modernization efforts in all business areas. 



39 



E. Components of the Evolving Information Systems 

The Corps of Engineers sees its future information systems evolving into five 
integrated application groups (Table 12). Of highest priority, Group One systems are 
those that have been initially identified as candidates for re-engineering (Table 11). 



IS GROUPING 


DESCRIPTION 


APPLICATION* 


GROUP 1 


Drivers 

High degree of shared 
data 

Critical to USACE 
mission 


Financial Management 

Payroll 

Real Estate 


GROUP 2 


Compliment Group 1 
Subject Specific 


Safety Information 
Management Database 
Navigable Waterways 
subject database 


GROUP 3 


Housekeeping 
Highly subject 
specific 

Broad Spectrum of 
business functions 


National Inventory of 
Dams 

Career Program 
Management Database 


GROUP 4 


Decision Support 


Executive Information 


GROUP 5 

* Representative listing 


Library and legal 
support 


Historic Databases 



Table 12. USAGE Information Systems Groupings 
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IV. USAGE Re-Engineering Process 



As a result of the modernization effort, USAGE has developed an innovative 
approach to business re-engineering that results in the evolution of critical information 
systems in support of major business processes or missions.^® The methodology 
incorporates the use of a technique adapted for USAGE needs. The final result is a 
pragmatic and adaptive approach to IS development. 

A. USAGE - A Pragmatic Approach to Information Systems 
Development 

As shown in Figure 7, USAGE has outlined a strategy consisting of four major 
organizational activities and their IS counterparts. 

1 . ISP/ISPI Completion 

The first step in any modernization program is the completion of strategic and 
tactical plans that form the foundation for business re-engineering. USAGE strategy 
incorporates the use of the Information Systems Plan (ISP), and the Information Systems 
Planning Implementation (ISPI) report. 

The ISP provides a strategic plan that relates information requirements to mission 
goals and objectives. An information architecture is defined, and an action plan 
recommending specific improvement activities is set forth. 

USAGE efforts included the use of the Headquarters level ISP, conducted in 
1984, and 57 field level ISP’s conducted between 1984 and 1989. 



^®With or without information systems support, the organization still has to deal with technical 
difficulties that are inherent in the way it conducts business. 



41 



Infotmation Systems Plan / 
/ ISP 


\ Strategic Planning 

sp\ 


Infotmadon Systems 
Planning Implementation 


/ ISPI 


TP 


Tactical Planning 

V 


Structured Requirements / 
and Analysis Planning / 


STRAP 


A&DM 


\ Activity and 
\ Data Modeling 


Prototype / 

Development / 
Concept / 


PDC 


PDA 


\Pliysical Database 
^application 



Figure 7. Mapping USAGE IS Activities to Organizational Counterparts 



Following the ISP, an ISPI is produced. This tactical plan establishes information 
architectures, creates project slates, and establishes the IS management structure. The 
ISPI project slate identifies candidates for re-engineering that form the foundation of the 
modernization effort. Again USAGE efforts included both headquarters and field level 
ISPI’s. 

2. Business Re-Engineering Process Model — Producing the Structured 
Requirement Analysis and Planning (STRAP) Report 

Process and data requirements of a particular functional application area are 
analyzed and documented in the Structured Requirements and Analysis Planning (STRAP) 
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Report. Producing this report uses a team approach that involves functional 
participation. Business activities are modeled, and result in a blueprint for further 
development. Figure 8 describes the business process re-engineering model. 

a. Selection of Team Members and Team Composition 

Once an existing application has been identified as a candidate for re-engineering, 
an application development team must be formed. The project leader is assigned 
approximately two weeks in advance of the start of the actual development effort to 
prepare for the task at hand. The project leader serves as both a working member of the 
team and as team leader, assuming a position of coordination between the team and the 
sponsor of the application being developed. This role calls for business system skills as 
well as effective leadership abilities. 

Application development teams vary in size depending upon the application 
developed and the skills possessed by the various members of the team. In general, 
teams consist of six to eight individuals, with additional functional members on call to 
support the team if requested. STRAP team members are selected by the project 
proponents with the following used as criteria for team selection: 

• A good working knowledge of USAGE policies which impact their functional 
areas and a knowledge of USAGE policies as a whole. 

• Broad experience which transverses different functional areas and organizational 
levels within USAGE. 

• A manager or assistant in multidisciplinary area. 

STRAP team members must be experienced with the overall mission and business 
practices of USAGE. They must be willing to try new methods and apply innovative 
ideas to application development. Table 14 depicts the generic team composition and the 
roles fulfilled by team members. Most of the members come from USAGE with a few 
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Figure 8. Business Process Re-Engineering Model 
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contractors providing instruction, modeling and administrative support.^* 







ROLE 




• 


PROJECT LEADER 




• 


FACILITATOR 




• 


FUNCTIONAL USERS 

- SUBJECT MATTER EXPERTS 

- LIBRARIAN 

- USER MANUAL DOCUMENTER 




• 


REVIEWER 




• 


END USERS 




• 


APPLICATION DEVELOPERS 

- TECHNICAL LIBRARIAN 

- USER MANUAL DEVELOPER 




• 


HARDWARE/SOFTWARE SUPPORT 




• 


DATA ADMINISTRATOR SUPPORT 




• 


ADMINISTRATIVE SUPPORT 



Table 14. Generic Team Composition 



T\vtfacilitator is a USAGE employee or a contractor knowledgeable in application 
development tools and techniques (i.e., IDEE tools and prototyping) and data-driven 
user-oriented information systems. 



^‘"U.S. Army Corps of Engineers Information Engineering: Application Development 

Project Leaders Reference Manual", March 1, 1991. 
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A functional user must have a broad perspective of how the USAGE conducts 
operations in his or her functional area. Users come from a wide range of management 
levels within USAGE, and are key to the success of the application development process. 

The librarian collects, catalogs, and maintains sample reports, documentation, and 
any references that a team may use during the development process. The technical 
librarian is responsible for the management of the software tools being used as the 
application modules are developed, and for keeping logs of the latest updates. 

The data manager performs both data administration and database administration 
functions for the project. He or she maintains the conceptual data model as well as the 
physical model. 

Application programmers should possess strong programming skills in high-level 
computer languages, particularly 4GLs or I-GASE products. They may be involved in 
the development of activity models with functional team members in order to gain an 
understanding of the relationships represented by the models. Programmers transform 
the functional description into the actual working application. 

b. Training of Team Members 

Team members must possess a wide variety of skills to ensure a successful 
application development effort. They must have knowledge concerning all phases of the 
application development process and the skills listed in Table 15. Each member need not 
possess all skills, and not every application requires all of these skills, yet they are 
representative of the skills required to develop an application successfully. 

Team members initially were trained in modeling techniques and application 
development by personnel working under contract for USAGE.^^ After this initial 
training, USAGE uses its own personnel to train future team members. 



“USAGE training was conducted by D. Appleton Company. The approximate cost of this 
training (10-15 people) was $10.5K. 
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DEVELOPMENT PHASE 
Planning Requirements and Design 



Development of Interactive Relational 
Database Information Systems 



Data and Database Administration, 
Performance Tuning 



Functional User Design and Evaluation 



Concepts and Operations of New 
Applications 



REQUIRED SKILLS 

•ISMP goals and objectives 
•LCMIS and information engineering 
•Application development project 
methodology 

•IDEF modeling techniques overview 
•USAGE data administration goals and 
objectives 

•Relational database concepts 
•Oracle and SQL for developers 
•COBOL programming for SQL databases 
•Oracle client server architecture 

•Oracle database administration, 
application tuning, and client server 
performance analysis 
•NOS/VSE file management optimization 
and communications in the client server 
mode 

•Introduction to SQL for end users 
•Oracle for end users 
•SQL forms and report writers for end 
users 

•Conversion tool use 
•Manual conversion procedures 
•Overview of conceptual design of 
application 

•Procedures for the new application 



Table 15. Skill Requirements 



c. Conduct Activity-Based Costing Baseline 

The main purpose of the ABC baseline is to acquaint members with the design 
tools (i.e., IDEF). Some participants are familiar with current business practices, 
operating procedures, and costs of activities. IDEF techniques are used to model these 
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processes ("AS-IS" models). This gives team members the opportunity to experiment 
and become proficient in IDEF modeling. 



d. Condua Activity-Based Cost Alternatives 

After the business process is broken down into distinct activities in the "AS-IS" 
models, ABC is then used to analyze activity models (see Appendix B). Activities are 
determined to be either value-added or non-value added. A non -value added activity 
becomes a candidate for elimination or improvement. The results of the ABC analysis 
form the baseline for improvement action within the business process. 

e. Implement Improvement Actions 

An important step is to identify changes to the business process that can be 
improved without further analysis or approval. These improvement opportunities will 
be the foundation for the formulation of "TO-BE" process models which are formulated 
in the next phase of the business re-engineering methodology. 

f. Conduct Business Process Modeling 

Once the current system is analyzed and improvement actions identified, the team 
once again uses IDEF techniques to build "TO-BE" activity and data models of the 
system. These "TO-BE" models show how the business activities will perform once 
they are modernized. They are developed from the ground up with little or no reference 
to the existing process. Team experience and knowledge of the functional area being 
covered allow them to develop the future systems as they would like to see them 
operate. Usually, more than one "TO-BE" model is developed to examine alternatives 
before deciding on the final one. An initial data model is developed by extracting a 
subset of the command data model.^^ Additional data elements are added to the model 



Command Data Model (CDM) is a graphical depiction of all USAGE entities, data 
elements, and their relationships. This model is continually being developed as part of the overall 
modernization effort. The CDM provides the basic framework for all business systems 
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as necessary after approved by the Data Scrub Review Committee for use throughout 
USAGE. 

g. Build Business Case 

The "TO-BE" models developed are now examined and evaluated. For each 
alternative, costs are identified, potential benefits determined, and risks assessed. This 
economic analysis serves as a basis for selecting the model to be developed. 

h. Develop Transition Plan 

The team must develop a project implementation plan. Included in this plan is 
the preferred project solution alternative and the reason for selecting it. The staging, 
resourcing, and sequencing of related actions are determined and a preliminary project 
schedule is drafted. 



The final result of the business re-engineering methodology is the STRAP report. 
This report constitutes the foundation upon which targeted applications will be developed. 
It consists of the functional specifications of a proposed information system — i.e., the 
"TO-BE" activity model and its corresponding data model along with the proposed 
milestones for project completion. 

4. Prototype Development Concept — from Design to Implementation 

Prototype Development Concepts (PDC’S) are more technical in nature than the 
STRAP and provide the details necessary to actually build the systems defined in the 
STRAPS. The result is a fully working prototype that will be deployed for US ACE-wide 
use. 



development depending on shared data. 
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a. Conceptual Design 

Following the conceptual development and planning phase, functional 
requirements defined in the STRAP report are translated into a functional design 
description. 

User application interfaces, bridges to other systems within USAGE corporate 
architecture, and documentation of the necessary business controls are defined. The 
technical requirements for hardware, software, communications, security, and 
performance are also specified at this time. 

Finally, the team surveys existing software applications that might be re-used as 
part of the proposed system. It also establishes guidelines for the procurement process 
if such an application is available and selected. No selection is made at this time as to 
whether or not an existing "commercial off the shelf (COTS) application will be 
procured by USAGE. 

b. Acquire Application 

The acquisition phase uses the design documentation and the list of existing 
available COTS applications to evaluate the packages available from commercial vendors 
or other government agencies. A Request-for-Proposal is drafted from the functional 
description and sent to potential COTS suppliers. Proposals received from suppliers are 
evaluated and the functional capabilities are compared with the requirements defined in 
the STRAP. The databases of the proposed systems are evaluated and a data model of 
the system is prepared to compare how thoroughly the proposed system databases meets 
the data requirements of the USAGE model system. If an off-the-shelf system is 
selected, a contract for modification, transfer of technology, and maintenance is 
negotiated with the supplier. Eventually, the selected COTS system will become an 
integral part of the proposed system. 
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c. Iterative Application Development 

If no COTS application meets USAGE specifications a new application must be 
developed. Beginning with the functional description written during the design phase, 
a prototype of the application is developed. The key to the success of prototyping is to 
involve functional users in the continual evaluation and improvement of the system being 
developed. During this iterative process, users participate in the testing and evaluation 
of the emerging system, noting its deficiencies and suggesting design improvements. 
Corrections and enhancements are then made, and the improved version is resubmitted 
to users for evaluation. The functional description is updated to reflect the changes. 

When all of the components of the application have been developed, they are 
integrated in preparation for "alpha testing" — i.e., internal systems testing. The 
functional description is updated and finalized, all program modules are recompiled and 
loaded, the test database and user documents are reviewed, and a proposed operations 
manual is drafted. 

The integrated application undergoes a comprehensive functional test that 
encompasses user application interfaces, bridges to other USAGE information systems, 
and the batch programs. Following the alpha test, an in-process review is conducted 
and the results of the testing are evaluated and necessary changes are made. Following 
this, approval is granted for advancement to "beta testing" — i.e., testing by a selected 
group of users. 

d. Perform Integration and Beta Testing 

The application is designed to fully integrate into the overall USAGE architecture. 

Some integration is done during the system development, but final integration with the 
existing architecture is normally required. 

Gorrections, improvements, and enhancements that were identified during the 
alpha testing are programmed at this time. User documentation is updated to reflect 
these changes and the system is integrated with the Gommand Data Model. A second 
alpha test is then performed, and the system is also tested in the environment in which 



51 



it will operate. This testing aims to verify that the new application will operate in 
conjunction with existing systems. 

Beta tests are performed in operational environments at multiple test sites. The 
new application is installed at a test site. Operators and end users are trained in the use 
of the application. The new application is usually operated in parallel with the existing 
information system or manual procedures. End users document any problems that arise 
as a result of the new application and evaluate the application in terms of effectiveness 
and performance level. Upon completion of the beta test, another in-process review is 
conducted and a recommendation is made for either deployment or continued 
improvement of the application. 

e. Perform Operational Transition and Deployment 

During the final phase of business re-engineering procedure the application is 
placed into operation. 

A transition plan and deployment schedule is developed that considers issues such 
as the full-scale conversion of data, training of users, training of operations staff, 
bridging the system into currently existing systems, and scheduling the acquisition of 
hardware, software, and communications. Actual deployments at specific sites are 
scheduled at this time. 

Following these steps, the application is packaged for delivery to end users. This 
involves preparing the necessary software, documentation materials, and training plan. 
When the package is delivered, the application development team turns over 
responsibility for management and maintenance to the appropriate support team. This 
team installs the actual hardware, software, and communications required at each site. 

The final step in the implementation involves the training of site personnel, 
including both end users and operators, on the operation of the new application. In 
addition, local management is briefed on the scope and basic functionality of the 
application. 
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When the entire application is in place at a particular site, users will begin to 
operate the new system either in parallel with the existing system or independently as 
appropriate. The initial six-month period is used to provide feedback to the proponent 
in the effectiveness of the new application and to propose any major changes that may 
be necessary. Following this phase, the system is fully operational. 
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V. Lessons Learned 



A. Top Management Support is Critical 

The commitment and support of top management is critical to the success of any 
business re-engineering effort. Top management must see information as a strategic 
asset, link re-engineering to mission effectiveness, and fully support the efforts of the 
information modernization team. Any fundamental change in the organization is 
impossible without such support. As the second highest ranking officer within USAGE, 
the senior IRM official possesses the authority commensurate with this responsibility to 
effect change within the IRM organization. 

B. Business Re-engineering Drives Information Systems Design 

USAGE has determined that 85 percent of its improvement opportunities are 
related to the business procedures and not to automation alone. This is critical to 
understanding the importance of business re-engineering. Organizations are often 
enthusiastic about automation, yet they must realize that if the business processes 
underlying the automation effort are inefficient, the automation will be futile. 

The goal of business re-engineering is to rethink the way an organization operates. 
Gomputer systems development can no longer be solely justified as a means of 
automating existing inefficient business practices. The systems must be designed to 
incorporate new and innovative business practices. These practices can only be 
discovered through an extensive business re-engineering effort. 

USAGE has demonstrated that successful re-engineering is dependent on an 
incremental and pragmatic approach to business process re-engineering. The business 
processes of the organization must be broken up into projects of manageable size. The 
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organization must not attempt to re-engineer without an understanding of the underlying 
business processes. When these processes are understood and have been redefined, they 
must be integrated with each other in order to form the overall business process for the 
organization. 

A focus on business processes does not in any way minimize the critical 
importance of information technology. Although technology should not drive changes 
in business processes, it often enables changes that would otherwise not be feasible. 

C. Use of Committees to Solidify Results 

Teamwork constitutes the cornerstone of TQM. Committee-oriented decisions 
promote cooperation, non-hierarchical posturing, and effective problem solving. USAGE 
has demonstrated adept use of the committee decision making process in the development 
of management information systems. Collaborative group work is especially suitable to 
re-engineer mission-essential applications. 

The involvement of high level functional managers has proven to be a key to the 
success of the re-engineering effort. By bringing these managers together and forming 
a top-level decision making committee, priorities and functional specifications can be set 
to reflect the overall mission of the organization. Collectively, USAGE’S IRMSC and 
the associated Executive Committee and sub-committees determine the direction of future 
modernization programs. 

D. Involvement of Functional Managers is Fundamental 

Critical to the success of re-engineering is the active participation of functional 
managers in the process. Functional managers have a clear understanding of the business 
processes taking place. Their cooperation with the information resource staff 
significantly improves the quality of improvement and changes to the systems. New 
systems tend to be cross-functional and so it is necessary to get the joint participation of 
all functional managers whose areas of responsibility will be affected by a system 
change. 
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E. Role of a Consultant 



Implementing a successful information system calls for a combination of a sound 
understanding of the business process and a strong grasp of the appropriate information 
technologies. It is fairly unusual for an individual team member to have solid credentials 
across this wide spectrum. The team as a whole typically encompasses the necessary 
business and technical skills, but it is not easy to integrate across such disparate 
individual backgrounds. A good consultant brings to a project a broad set of talents that 
supplement those of the team. The skills and experience necessary to do this well are 
quite rare. Therefore most projects cannot employ such a person on a full-time basis. 
A consultant, however, may be able to contribute concurrently to several projects, 
thereby leveraging his or her expertise in an effective way. These skills may be obtained 
from an outside consulting firm or, very often, through an internal staff having a 
similarly broad set of skills. 

F. Role of Executive Champions 

The role of "executive champions" is another critical success factor. Proponents 
of a modernization program must seek out managers at all levels who take risks and are 
willing to try new and innovative business methods. They must not be afraid to change 
the way they work and to change the way that information is viewed by the organization. 
The managers who realize that successful information management and data sharing are 
key to the increased efficiency of operations must be at the forefront of the modernization 
program. 

G. Need for a Well-Structured Methodology and Training 

A successful re-engineering effort is dependent upon the adoption of a structured 
information engineering methodology supported by a commercial-off-the-shelf (COTS) 
software tool that can be tailored to meet organizational needs. 
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USAGE has demonstrated success in using the Structured Requirements Analysis 
and Planning (STRAP) methodology, a process in which the information requirements 
of a business are analyzed and documented, and has proven that it does provide a 
structured approach to the analysis of business processes. 

Critical to the success of such a methodology is the training of the individuals 
who are involved in the re-engineering efforts. USAGE experience has demonstrated the 
invaluable benefits of having trained team members in appropriate areas of systems 
development, particularly areas such as IDEE and ABC. Training and orientation require 
up-front costs, but the investment is essential. 

H. Use of Activity-Based Management and Costing in Conjunction 
with IDEF Activity Modeling 

ABC has been used successfully in the commercial sector. The experience of 
USAGE has shown that DoD agencies can incorporate such a tool into a comprehensive 
business re-engineering methodology. This methodology is being exported as a standard 
throughout the Department of Defense. 

USAGE has demonstrated that ABC, used in combination with well-proven 
structured activity and data modeling techniques such as IDEF, provides a powerful tool 
for accomplishing business re-engineering. Structured techniques allow managers to 
simplify the view of the business process and to establish a well-defined audit trail to 
support the continuous review process. Furthermore, ABC techniques provide essential 
inputs necessary to identify activities that must be eliminated or improved. 



I. Critical Role of On-Line User Support 

The role of on-line user support is crucial to the future of systems development. 
Realizing this critical issue, USAGE has designed its systems so that users of the 
systems are the direct recipients of the data. Whenever possible, the role of an 
intermediary — i.e., a computer operator — between the systems and the users should 
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be eliminated. Managers will have direct and fast access to the data critical to making 
timely and correct decisions. 

J. Central Role of Data Modeling 

As part of the USAGE 1995 architecture goals, data are viewed as critical system 
resources. Consistent with this view, USAGE has moved to data centralization and 
standardization. A system of reviewing and approving data elements was developed, it 
consists of three steps: submission of data elements, approval by the data scrub review 
committee, and certification as standard USAGE data elements. Currently USAGE has 
approximately 2000 data elements at the "approved level." These represent 
approximately 80 percent of the data elements that will be required by the 1995 
architecture.^ 

Standardized data modeling has several advantages. During the data review 
process, USAGE realized that over 40 percent of its current elements were redundant, 
causing added costs, errors, and inconsistencies. With data standardization, data are 
separated from applications, entered once at the source, and shared by all. By this 
means, the inconsistency and increased overhead associated with redundant data can be 
substantially reduced. USAGE uses only the essential data to manage its information. 
This minimization of data elements improves information quality, timeliness, and access. 



^Spivey Interview 
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CRITICAL ISSUES 




USAGE IMPLEMENTATION 


LEADERSHIP 


• Senior Management 

Commitment 


• 


Deputy USAGE commander is senior 
IRM official 


MANAGEMENT 


• Functional managers are key 

to success 


• 


IRMSC comprised of top-level 
functional managers 
Application development teams involve 
middle-level functional managers 


• Change Agents essential 


• 


Executive champions sought at all levels 


• Consensual decision making 


• 


Use of committee work to solidify 
results 


STRATEGY 


• Re-engineering effort operates 

as a natural business process 


• 


Use of a well-established and 
comprehensive planning program 


• Business process drives IS 

design 


• 


Re-engineering business processes prior 
to automation 


METHODOLOGY 


• Focus on business processes 


• 


Use of ISP, ISPI, and STRAP 
methodologies 


♦ Use of structured methodology 

that can be universally applied 


• 


IDEF in conjunction with ABC 


• Data modeling and 

standardization are essential 


• 


Creation of the command data model 
and command data dictionary in 
conjunction with USAGE data 
administration program 



Table 16. Summary of Lessons Learned 
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Appendix A. An Overview of the IDEF Technique 



IDEF (Integrated Computer Aided Manufacturing Definition) is a modeling 
technique used to graphically represent business processes. Based on Structured Analysis 
and Design Technique (SADT) developed by SOFTECH in the 1970’ s, IDEF is a 
structured and proven methodology that has been widely used throughout industry and 
government. IDEF refers to two diagramming methods. IDEFO is used for functional 
activity modeling, while IDEFIX is used for data modeling. 

The IDEFO modeling technique was developed by the U.S. Air Force as part of 
their Integrated Computer Aided Manufacturing (ICAM) project. The goal of IDEFO is 
to provide a graphical framework for hierarchically decomposing and representing the 
business process as a collection of related functions and activities. 

Activities are the center of IDEFO. An activity is an action that occurs within 
a business process that has a recognizable outcome. Symbols are used to represent 
activities and information flows. Activities in IDEF are represented by boxes (Figure 
Al.) The text within the box is the name of the activity itself. Activity names are 
typically verbs or verb phrases. The arrows represent information flow and have specific 
meanings. Arrows entering the left side of the activity box represent inputs — those 
items which are consumed or transformed by the activity. Controls are represented by 
the arrows entering the top of the box and are those factors that constrain or influence 
how an activity is to be performed (i.e., existing regulations, prior personnel 
commitments). The right side of the box is reserved for the outputs or the product of 
the activity. The arrows entering the bottom of the activity box represent mechanisms 
— the people or tools used to perform the activity. 

Collectively these information flows are referred to as "ICOMS" (derived from 
taking the first letter of the name of each information flow. All ICOM’s are given a title 
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C»NTROLS 



INPUTS 




OUTPUTS 



Figure Al. An Example of a Generic IDEF Activity Model 



and a glossary defining each ICOM and activity accompanies the models. IDEF uses four 
types of activity diagrams to represent the business process: 



Node Trees (Figure A2) - A representation of the activities without the associated 
ICOM’s. The dots on the tree represent an activity, while the lines of the tree 
represent a decomposition relationship between activities. A node allows the re- 
engineering team to see how the activities are related hierarchically, and to get 
an overall view of the business process. They can determine which activities are 
actually part of their program and which activities are outside the scope of their 
efforts. 
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• Context Diagrams (Figure A3) - A representation of the highest level activity and 
its associated ICOM’s. The highest level activity is the entire process being 
modeled. 

• Decomposition Diagrams (Figure A4) - A breakdown of the context diagram into 
subactivities and associated ICOM’s. 

• FEO (For Exposition Only) diagrams - Used to focus in on a particular portion 
of a decomposition diagram. 

The ability of IDEF to decompose processes hierarchically is its strongest feature 
and makes it particularly suitable to re-engineering. Users of the IDEF modeling 
techniques can examine any portion of the business process in great detail since a given 
process can be broken down into several sub-processes. This feature allows the re- 
engineering team to view the complete business process in detail and to identify those 
non-value added activities that are the target for elimination in any program of re- 
engineering. IDEF can be used to model the "AS-IS" process from which the cost 
drivers are identified and then to model the "TO-BE" process with un-needed cost drivers 
eliminated and a more efficient process defined. 
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Figure A2. An Example of a Node Tree 
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Figure A3. An Example of a Context Diagram 
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Figure A4. An Example of a Decomposition Diagram 
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Appendix B. Procedures for Activity Based Costing — 
Determining Activity Costs Through IDEFO Modeling 



ABC recognizes the causal relationships of cost drivers to activities. Practitioners 
of Activity Based Management (ABM) analyze activity costs and focus on the 
management of these activities. The goal is to improve the value received by the 
customer in terms of increased profit or benefits received. 
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ABC used in conjunction with IDEFO modeling brings together the factors 
necessary to aid decision makers in identifying and implementing improvement 
opportunities. ABC consists of fives phases (Figure Bl). Each phase is accomplished 
in sequence by a small group of persons called the team to establish a baseline for 
activity cost performance. Once trained in the techniques of breaking down activities 
into cost factors the team assists functional users in gathering costs, defining activity-cost 
concerns, and constructing ABM cost databases. Once a validated cost database is 
established, updating cost data becomes an easy task to be performed on an annual basis. 

A. Analyze Activities 

Operating management decides the scope of activities, often numbering in the 
dozens, to be analyzed. The program should encompass six to ten units within the 
organization that have common functional areas stemming from the same budgetary 
appropriation. IDEFO is used to create "AS-IS" models of the business process. The 
activities identified through this modeling technique are those which form the foundation 
for ABC analysis. These models are validated and processes analyzed to characterize 
activities as either value-added or non-valued-added. 

B. Gather Costs 

At the same time activities are analyzed the Team examines historic data to collect 
cost information associated with the business process. These costs will later be traced 
to specific activities to facilitate the identification of cost improvement opportunities. 
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C. Trace Costs to Activities 



This phase merges the results of activity analysis and cost-gathering to produce 
an input cost for each activity. It is these input costs that are used as part of the output 
measure. 

D. Establish Output Measures 

The next step is to calculate the activity unit cost. One primary output must be 
identified for each activity. The output must be quantifiable. Activity unit cost is 
determined by dividing the input cost by the output volume. 

E. Analyze Costs 

Analyze costs uses information derived from the previous phases to determine 
improvement opportunities. Non-value-added activities are identified and become 
candidates for modernization or elimination. 
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Glossary of Terms 



ACTIVITY - A business process, function, or task occurring over time with recognizable 
results. Activities are represented in an activity model with identifiable inputs, controls, outputs, 
and mechanisms. 

ACTIVITY-BASED MANAGEMENT (ABM) METHODOLOGY - A prescribed process that 
puts activity-based costing (ABC) theories into practice. It includes the breakdown of an 
enterprise into manageable segments for detailed analysis regarding cost and performance, aimed 
at effective and consistent organization of the enterprise’s activities, continuous process 
improvement, and the elimination of waste. 

ACTIVITY MODEL - A model that describes the business activities for a particular 
environment. The activity model depicts how activities relate to one another and the use of the 
environment in a pictorial format with various levels of detail. 

ACTIVITY MODELING TECHNIQUE - A technique that defines both the AS-IS and TO-BE 
environments. This is a description from the external user’s view. 

ACTIVITY OUTPUT - The product of an activity. What internal or external customers receive 
and what the organization produces — e.g., a paycheck, widget, or some type of service. 

ACTIVITY PERFORMANCE MEASURE - A quantifiable measure of the cost of performing 
an activity, a measure of time required, and how well an activity was performed. 

ALPHA TEST - A set of scheduled internal tests to demonstrate the correctness and 
completeness of conceptual logic models, internal physical database models, application 
development projects, user documentation, and Standard Operating Procedures (SOP’s) within 
normal limits. 

APPLICATION - The user’s interface into the system, the window into the database. The User 
Interface Application requirements defined in the conceptual design are the actual application 
components that provide service to end users. 

APPLICATION DEVELOPMENT TEAM - A group of functional users and technical 
specialists whose primary function is to oversee the requirements specification, design 
development, programming and implementation of a information systems application. 
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AS-IS MODEL - A diagrammatic illustration of the business process as it currently exists. 

BETA TEST - The Beta Test is a normal working environment test. It is a user software 
acceptance test of a new system or changes to a deployed system. The Beta Test is conducted 
in a field environment using a production "live" database executed on designated hardware. 

BUSINESS PROCESS - A group of logically related decisions and activities required to 
manage the resources of a business. The linkage of activities across functional boundaries. 

CASE (Computer Aided Software Engineering) - Collective reference to a family of software 
development productivity tools. 

CIVIL WORKS PROGRAM - Major USACE mission area that includes water resource 
management and emergency response programs. 

COMMAND DATA MODEL - A fully attributed conceptual data model that is the overall 
logical structure of the Corps of Engineers data, independent of any software or storage 
constraints. It may often contain data structures not yet implemented in intemal/physical data 
models. 

COST DRIVER - Factors of an Activity that lead directly to expenditures and create costs. 

DATA - Meaningful facts about persons, places, things, concepts, events, and activities in a 
defined format and structure from which information may be derived. 

DATA ELEMENT - A property or characteristic of a real world object. A data element has a 
name and a definition. Data elements are used to distinguish between real world objects and to 
provide descriptions of them. Data elements are named with singular nouns. 

DATA MODEL - A model that described real world objects, their data elements and 
relationships that comprise the data that describe the business environment and support the 
activity model. 

END USER - A person who uses the information or data provided by a computer system. For 
example, engineers, secretaries, and managers are ail end users. 

FOURTH GENERATION LANGUAGE (4GL) - Programming language that uses high-level 
human-like instructions to retrieve and format data for inquiries and reports. 

FUNCTIONAL USER/CUSTOMER - The responsible Corps individual who oversees and 
manages an Application Development project or a STRAP. 

GAO/IMTEC - General Accounting Office Information Management Technology report. 

IDEF (Integrated Computer-Aided Manufacturing Definitions) MODEL - A semantic 
language based representation of complex real world activities and their interdependencies. These 
interdependencies are classified as either inputs, controls, outputs, or mechanisms (ICOMS). 
IDEF models provide an understanding of the activities in the environment and their use of 
information. 
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IMPROVEMENT OPPORTUNITIES - Identified during the definition of the AS-IS Model, 
they represent the areas of importance to be focused on during the To-Be modeling process. 

IN-PROCESS REVIEW (IPR) - A review by a team of functional and technical delegates to 
determine if the requirements of a business area are being satisfied in an efficient manner by the 
Application Development effort. 

INFORMATION RESOURCE MANAGEMENT STEERING COMMITTEE a^MSC) - 
Made up of the senior personnel from the major directorates and offices in the Headquarters to 
be concerned with strategic issues (such as appeal on data naming issues). 

ISP - Information System Plan 

ISPI - Information System Planning Implementation 

LIFE CYCLE MANAGEMENT - The control and administration of an information system 
throughout its entire existence, from system development to replacement. 

NON-VALUE ADDED ACTIVITIES - Anything other than the minimum amount of equipment, 
materials, space, and employee essential to achieve corporate objectives and remain an ongoing 
enterprise (e.g., correction, inspection, expediting delay, storage, etc.). 

PROCESS MODEL - Pictorial representation of logically related decisions and activities using 
an accepted modeling technique. 

PROPONENT - The USAGE organization that is responsible for the definition of the entity 
and/or data element. 

STOVEPIPE SYSTEM - A separately developed information system without shared data and/or 
resources. 

STRAP (Structured Requirements Analysis and Planning) Report - Process and data 
information requirements of a business are analyzed and documented. A Business Process is 
selected from those projects slated during Information Systems Planning Implementation (ISPI). 
The overall information requirements are identified and projects proposed to implement these 
needs. 

TO-BE MODEL - Diagrammatic illustration of the incorporation of business process 
Improvement Opportunities with the Command Data Model concept of shareable data across 
business processes. 

VALUE ADDED ACTIVITIES - Contribute to the achievement of enterprise activities and/or 
to product attributes and service level paid by the customer. 
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